Tom,

Machine Description( CNC router with Kflop/Kanalog controlling servo drives.  Encoder feedback to Kanalog and drive control with -10/+10)

Was running a long job yesterday, takes about 5 hours, at about the 4 hour mark Mach3 stopped and I got an error. 

"DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"

This is the second time this has happened to me.    First time was a week ago with a different cut file.   I rebooted.  Went to Kmotion and went through the firmware upgrade process and machine told me the latest version of firmware was installed.    Went back to using machine and all seemed well.

This time I didn't didn't do anything but close the Mach3 application and reopen it.   All seemed well.

Since I don't think the firmware can change itself in the middle of a running job this error message must have a deeper meaning.   What are the other causes of this error when the firmware is up to date.

Thanks,

Barry

Hi Barry,

Strange.  Before Compiling any C Program for KFLOP the Compiler checks if the Firmware Time Stamp in KFLOP matches the Firmware File on the PC.  Apparently they somehow don't match.  One or the other must be being miss-read.  The error message should include both Time Stamps.  Do you recall what they were?  Did they look valid or corrupted?  Which one was correct?

I assume your GCode contains either Spindle commands or M Codes that would cause C Programs to be executed in KFLOP.  You might run KMotion.exe and open the Console Screen to see if anything unusual is displayed.  We often include diagnostic printf messages in the C Programs to help know what commands/programs are doing.  You might remove those to see if it helps.

Any prior history?  Have you ran long jobs before without problems?  Anything changed?  What Version of Windows, KMotion, and Mach3 are you using?

Could the PC be going to Sleep?

Regards

TK

 

Tom,

Machine Description( CNC router with Kflop/Kanalog controlling servo drives.  Encoder feedback to Kanalog and drive control with -10/+10)

Was running a long job yesterday, takes about 5 hours, at about the 4 hour mark Mach3 stopped and I got an error. 

"DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"

This is the second time this has happened to me.    First time was a week ago with a different cut file.   I rebooted.  Went to Kmotion and went through the firmware upgrade process and machine told me the latest version of firmware was installed.    Went back to using machine and all seemed well.

This time I didn't didn't do anything but close the Mach3 application and reopen it.   All seemed well.

Since I don't think the firmware can change itself in the middle of a running job this error message must have a deeper meaning.   What are the other causes of this error when the firmware is up to date.

Thanks,

Barry

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

LastErrors-14465.txt
BarrysThermwoodRouterv2-14465.c

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

Hi Barry,

Regarding Drift:

I'm not sure exactly what you mean by "When I go to estop" and "when I come out of estop".

Actually Mach3 doesn't ever "control the drives".  It only sets/clears enable outputs and runs your init program.

You didn't tell us how you have Mach3 configured.  I'm guessing you have the Mach3 ports&pins Enable bits configured configured to also control your Amp enable bits (152 - 156)?  I think that may be the problem.  Mach3 intentionally sets the enable outputs one by one with delays (to supposedly avoid a current surge) and then does the Reset.  So in the mean time the drives may drift.  it would probably be better to set Mach3 to dummy bits and let KFLOP and your init program be in full control of the enables.

HTH

Regards

TK

 

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

The firmware message I get is "DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"  I'll get a screen shot the next time this happens.   These two issue happen infrequently.    The firmware issue has happened maybe 6 times and the Comm Error message only once.    I'll try to gather more info if you don't have any ideas at this time.


On another more straight forward issue.   I am controlling my drives with an analog signal.   As we've talked about before when kflop is not controlling the drive the voltage may not be exactly zero and I see some small movement in the drive.   I am working around this by using a disable input on the drive attached to output on kflop.    I've tied this output to the axis enable in my c program so that if the axis is disabled I turn on the output and disable the drive electrically.   This works fine in kmotion and keeps the drive from creeping.   I trigger this when I go to estop.   Problem is when I'm in Mach3.   When I go to estop all is well and works fine.    But when I come out of estop I have a issue.    When I electrically disengage the estop I think mach3 runs the c program.  Which re enables the drive but Mach3 doesn't start controlling the drive until I press the reset buttion in the Mach3 software.   So between those two steps the drive creeps.      I can see on the Mach3 software that it is monitoring the estop bit and the frame of the reset button changes color when I disengage the estop.     How can I keep my drives disabled until Mach3 is in control.    If there was a bit to look at I could just do an or condition with the estop bit.   Both would have to be ready before the drive was enabled.    Any thoughts on how I can do this.   Maybe you see another way to do my c program that will be better.    


I attached my c program file but here is the relative code to axis enabling at the end.



    EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);


    DefineCoordSystem(0,2,3,-1);


    for (;;)  //loop forever
    {
        WaitNextTimeSlice();

        // if ESTOP present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143
        if  (!(ReadBit(ESTOP_BIT)))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

         }

        // if Axis enabled , clear disabled bit
        if (ch0->Enable)
            ClearBit(152);
       
        if (ch1->Enable)
            ClearBit(153);   

        if (ch2->Enable)
            ClearBit(154);
                   
        if (ch3->Enable)
            ClearBit(155);
           
        if (ch4->Enable)
            ClearBit(156);

                                   
    }


return 0;

}

On 2/27/2017 2:55 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

Guess I didn't explain well.   Mach3 doesn't do anything to the kflop i/o that I've programed.   Kflop is in full control of all i/o.    I am controlling all i/o via the c program.    The question really is about what happens  between kflop and mach3 via the driver.

The goal is that I must keep bits 152 to 156 set anytime I'm in an estop condition or Mach3 is not control the position of the axis

"When I go to estop"  When I push my hardwired estop button power is removed from the drives and kflop input bit 143 is made active.    In my c program this disables all axis and sets bits 152 to 156.    This is all fine and works well and with bits 152 to 156 set no creep from the drives since the outputs are hardwired to the drive disable inputs.

"When I come out of estop" When I pull out my estop button power is turned on to the drives and kflop input bit 143 is made inactive.   

This is where I need advice.    The only i/o bit I have mapped between kflop and mach3 is the Estop bit.   It looks like mach3 reruns the c program when the estop bit is made inactive.    With my c program this renables the axis but mach3 isn't controlling the drives until I click the "software reset button" in Mach3.    So between pulling the estop button out and clicking the "software reset button" I get axis creep.

I don't want to clear bits 152 to 156 I'm not in estop confition AND until Mach3 is controlling the axis.   How can I do this.    With my c program it would be as simple as something like this if I knew a bit to look at.   Maybe you have a better idea.

// if ESTOP or Mach3 is not in control present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143

        #define Mach3InControl_BIT  ???

        if  (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

I see that Mach3 has enable 1 to 6 outputs.    Can't find any documentation that says what the do in Mach3.  am I over thinking this.  Can I just map those Mach3 enables bits to bits 152 to 156 in kflop.    If I knew how that react maybe is really is that simple and I don't need the c program to do it.

 

Hi Barry,

Regarding Drift:

I'm not sure exactly what you mean by "When I go to estop" and "when I come out of estop".

Actually Mach3 doesn't ever "control the drives".  It only sets/clears enable outputs and runs your init program.

You didn't tell us how you have Mach3 configured.  I'm guessing you have the Mach3 ports&pins Enable bits configured configured to also control your Amp enable bits (152 - 156)?  I think that may be the problem.  Mach3 intentionally sets the enable outputs one by one with delays (to supposedly avoid a current surge) and then does the Reset.  So in the mean time the drives may drift.  it would probably be better to set Mach3 to dummy bits and let KFLOP and your init program be in full control of the enables.

HTH

Regards

TK

On 3/2/2017 5:39 PM, harnett harnett@... [DynoMotion] wrote:

 

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

The firmware message I get is "DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"  I'll get a screen shot the next time this happens.   These two issue happen infrequently.    The firmware issue has happened maybe 6 times and the Comm Error message only once.    I'll try to gather more info if you don't have any ideas at this time.


On another more straight forward issue.   I am controlling my drives with an analog signal.   As we've talked about before when kflop is not controlling the drive the voltage may not be exactly zero and I see some small movement in the drive.   I am working around this by using a disable input on the drive attached to output on kflop.    I've tied this output to the axis enable in my c program so that if the axis is disabled I turn on the output and disable the drive electrically.   This works fine in kmotion and keeps the drive from creeping.   I trigger this when I go to estop.   Problem is when I'm in Mach3.   When I go to estop all is well and works fine.    But when I come out of estop I have a issue.    When I electrically disengage the estop I think mach3 runs the c program.  Which re enables the drive but Mach3 doesn't start controlling the drive until I press the reset buttion in the Mach3 software.   So between those two steps the drive creeps.      I can see on the Mach3 software that it is monitoring the estop bit and the frame of the reset button changes color when I disengage the estop.     How can I keep my drives disabled until Mach3 is in control.    If there was a bit to look at I could just do an or condition with the estop bit.   Both would have to be ready before the drive was enabled.    Any thoughts on how I can do this.   Maybe you see another way to do my c program that will be better.    


I attached my c program file but here is the relative code to axis enabling at the end.



    EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);


    DefineCoordSystem(0,2,3,-1);


    for (;;)  //loop forever
    {
        WaitNextTimeSlice();

        // if ESTOP present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143
        if  (!(ReadBit(ESTOP_BIT)))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

         }

        // if Axis enabled , clear disabled bit
        if (ch0->Enable)
            ClearBit(152);
       
        if (ch1->Enable)
            ClearBit(153);   

        if (ch2->Enable)
            ClearBit(154);
                   
        if (ch3->Enable)
            ClearBit(155);
           
        if (ch4->Enable)
            ClearBit(156);

                                   
    }


return 0;

}

On 2/27/2017 2:55 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

 

Guess I didn't explain well.   Mach3 doesn't do anything to the kflop i/o that I've programed.   Kflop is in full control of all i/o.    I am controlling all i/o via the c program.    The question really is about what happens  between kflop and mach3 via the driver.

The goal is that I must keep bits 152 to 156 set anytime I'm in an estop condition or Mach3 is not control the position of the axis

"When I go to estop"  When I push my hardwired estop button power is removed from the drives and kflop input bit 143 is made active.    In my c program this disables all axis and sets bits 152 to 156.    This is all fine and works well and with bits 152 to 156 set no creep from the drives since the outputs are hardwired to the drive disable inputs.

"When I come out of estop" When I pull out my estop button power is turned on to the drives and kflop input bit 143 is made inactive.   

This is where I need advice.    The only i/o bit I have mapped between kflop and mach3 is the Estop bit.   It looks like mach3 reruns the c program when the estop bit is made inactive.    With my c program this renables the axis but mach3 isn't controlling the drives until I click the "software reset button" in Mach3.    So between pulling the estop button out and clicking the "software reset button" I get axis creep.

I don't want to clear bits 152 to 156 I'm not in estop confition AND until Mach3 is controlling the axis.   How can I do this.    With my c program it would be as simple as something like this if I knew a bit to look at.   Maybe you have a better idea.

// if ESTOP or Mach3 is not in control present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143

        #define Mach3InControl_BIT  ???

        if  (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

I see that Mach3 has enable 1 to 6 outputs.    Can't find any documentation that says what the do in Mach3.  am I over thinking this.  Can I just map those Mach3 enables bits to bits 152 to 156 in kflop.    If I knew how that react maybe is really is that simple and I don't need the c program to do it.

On 3/2/2017 10:37 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Regarding Drift:

I'm not sure exactly what you mean by "When I go to estop" and "when I come out of estop".

Actually Mach3 doesn't ever "control the drives".  It only sets/clears enable outputs and runs your init program.

You didn't tell us how you have Mach3 configured.  I'm guessing you have the Mach3 ports&pins Enable bits configured configured to also control your Amp enable bits (152 - 156)?  I think that may be the problem.  Mach3 intentionally sets the enable outputs one by one with delays (to supposedly avoid a current surge) and then does the Reset.  So in the mean time the drives may drift.  it would probably be better to set Mach3 to dummy bits and let KFLOP and your init program be in full control of the enables.

HTH

Regards

TK

On 3/2/2017 5:39 PM, harnett harnett@... [DynoMotion] wrote:

 

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

The firmware message I get is "DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"  I'll get a screen shot the next time this happens.   These two issue happen infrequently.    The firmware issue has happened maybe 6 times and the Comm Error message only once.    I'll try to gather more info if you don't have any ideas at this time.


On another more straight forward issue.   I am controlling my drives with an analog signal.   As we've talked about before when kflop is not controlling the drive the voltage may not be exactly zero and I see some small movement in the drive.   I am working around this by using a disable input on the drive attached to output on kflop.    I've tied this output to the axis enable in my c program so that if the axis is disabled I turn on the output and disable the drive electrically.   This works fine in kmotion and keeps the drive from creeping.   I trigger this when I go to estop.   Problem is when I'm in Mach3.   When I go to estop all is well and works fine.    But when I come out of estop I have a issue.    When I electrically disengage the estop I think mach3 runs the c program.  Which re enables the drive but Mach3 doesn't start controlling the drive until I press the reset buttion in the Mach3 software.   So between those two steps the drive creeps.      I can see on the Mach3 software that it is monitoring the estop bit and the frame of the reset button changes color when I disengage the estop.     How can I keep my drives disabled until Mach3 is in control.    If there was a bit to look at I could just do an or condition with the estop bit.   Both would have to be ready before the drive was enabled.    Any thoughts on how I can do this.   Maybe you see another way to do my c program that will be better.    


I attached my c program file but here is the relative code to axis enabling at the end.



    EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);


    DefineCoordSystem(0,2,3,-1);


    for (;;)  //loop forever
    {
        WaitNextTimeSlice();

        // if ESTOP present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143
        if  (!(ReadBit(ESTOP_BIT)))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

         }

        // if Axis enabled , clear disabled bit
        if (ch0->Enable)
            ClearBit(152);
       
        if (ch1->Enable)
            ClearBit(153);   

        if (ch2->Enable)
            ClearBit(154);
                   
        if (ch3->Enable)
            ClearBit(155);
           
        if (ch4->Enable)
            ClearBit(156);

                                   
    }


return 0;

}

On 2/27/2017 2:55 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

Hi Barry,

Ok I think I get it.

On a minor note,  I repeat,  Mach3 never really "controls the position of the axis" in a manner regarding drift.  KFLOP always controls the position of the axis to avoid drift  while an axis is enabled regardless of whether Mach3 is doing anything or not.  Mach3 can command KFLOP to move an axis somewhere.  But whether it does this or not will not result in drift.

Drift occurs simply when the Drives are enabled but the KFLOP Axes are not enabled.

Here is your drift scenario:

#1 EStop Bit active - your C Program loop Disables the Drives and Disables the KFLOP Axes

#2 EStop Bit deactiveated - your C Program Enables the Drives only - causing drift

What might work is to move the code that enables the drives before the loop to execute one time only whenever the Init Program is executed.  In this case:

#1 EStop Bit active - your C Program loop Disables the Drives and Disables the KFLOP Axes

#2 EStop Bit deactiveated - nothing really happens (except Mach3 is notified)

#3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and Drives

HTH

Regards

TK

 

Guess I didn't explain well.   Mach3 doesn't do anything to the kflop i/o that I've programed.   Kflop is in full control of all i/o.    I am controlling all i/o via the c program.    The question really is about what happens  between kflop and mach3 via the driver.

The goal is that I must keep bits 152 to 156 set anytime I'm in an estop condition or Mach3 is not control the position of the axis

"When I go to estop"  When I push my hardwired estop button power is removed from the drives and kflop input bit 143 is made active.    In my c program this disables all axis and sets bits 152 to 156.    This is all fine and works well and with bits 152 to 156 set no creep from the drives since the outputs are hardwired to the drive disable inputs.

"When I come out of estop" When I pull out my estop button power is turned on to the drives and kflop input bit 143 is made inactive.   

This is where I need advice.    The only i/o bit I have mapped between kflop and mach3 is the Estop bit.   It looks like mach3 reruns the c program when the estop bit is made inactive.    With my c program this renables the axis but mach3 isn't controlling the drives until I click the "software reset button" in Mach3.    So between pulling the estop button out and clicking the "software reset button" I get axis creep.

I don't want to clear bits 152 to 156 I'm not in estop confition AND until Mach3 is controlling the axis.   How can I do this.    With my c program it would be as simple as something like this if I knew a bit to look at.   Maybe you have a better idea.

// if ESTOP or Mach3 is not in control present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143

        #define Mach3InControl_BIT  ???

        if  (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

I see that Mach3 has enable 1 to 6 outputs.    Can't find any documentation that says what the do in Mach3.  am I over thinking this.  Can I just map those Mach3 enables bits to bits 152 to 156 in kflop.    If I knew how that react maybe is really is that simple and I don't need the c program to do it.

On 3/2/2017 10:37 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Regarding Drift:

I'm not sure exactly what you mean by "When I go to estop" and "when I come out of estop".

Actually Mach3 doesn't ever "control the drives".  It only sets/clears enable outputs and runs your init program.

You didn't tell us how you have Mach3 configured.  I'm guessing you have the Mach3 ports&pins Enable bits configured configured to also control your Amp enable bits (152 - 156)?  I think that may be the problem.  Mach3 intentionally sets the enable outputs one by one with delays (to supposedly avoid a current surge) and then does the Reset.  So in the mean time the drives may drift.  it would probably be better to set Mach3 to dummy bits and let KFLOP and your init program be in full control of the enables.

HTH

Regards

TK

On 3/2/2017 5:39 PM, harnett harnett@... [DynoMotion] wrote:

 

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

The firmware message I get is "DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"  I'll get a screen shot the next time this happens.   These two issue happen infrequently.    The firmware issue has happened maybe 6 times and the Comm Error message only once.    I'll try to gather more info if you don't have any ideas at this time.


On another more straight forward issue.   I am controlling my drives with an analog signal.   As we've talked about before when kflop is not controlling the drive the voltage may not be exactly zero and I see some small movement in the drive.   I am working around this by using a disable input on the drive attached to output on kflop.    I've tied this output to the axis enable in my c program so that if the axis is disabled I turn on the output and disable the drive electrically.   This works fine in kmotion and keeps the drive from creeping.   I trigger this when I go to estop.   Problem is when I'm in Mach3.   When I go to estop all is well and works fine.    But when I come out of estop I have a issue.    When I electrically disengage the estop I think mach3 runs the c program.  Which re enables the drive but Mach3 doesn't start controlling the drive until I press the reset buttion in the Mach3 software.   So between those two steps the drive creeps.      I can see on the Mach3 software that it is monitoring the estop bit and the frame of the reset button changes color when I disengage the estop.     How can I keep my drives disabled until Mach3 is in control.    If there was a bit to look at I could just do an or condition with the estop bit.   Both would have to be ready before the drive was enabled.    Any thoughts on how I can do this.   Maybe you see another way to do my c program that will be better.    


I attached my c program file but here is the relative code to axis enabling at the end.



    EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);


    DefineCoordSystem(0,2,3,-1);


    for (;;)  //loop forever
    {
        WaitNextTimeSlice();

        // if ESTOP present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143
        if  (!(ReadBit(ESTOP_BIT)))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

         }

        // if Axis enabled , clear disabled bit
        if (ch0->Enable)
            ClearBit(152);
       
        if (ch1->Enable)
            ClearBit(153);   

        if (ch2->Enable)
            ClearBit(154);
                   
        if (ch3->Enable)
            ClearBit(155);
           
        if (ch4->Enable)
            ClearBit(156);

                                   
    }


return 0;

}

On 2/27/2017 2:55 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

I'll try moving the code thanks.   It really doesn't need to be in the loop anyway.    I can see that BUT if Mach3 is not running the first part of Init.c until I press  reset then it really should work the way it is to right.

"What might work is to move the code that enables the drives before the loop to execute one time only whenever the Init Program is executed.  "

   EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);

 

Hi Barry,

Ok I think I get it.

On a minor note,  I repeat,  Mach3 never really "controls the position of the axis" in a manner regarding drift.  KFLOP always controls the position of the axis to avoid drift  while an axis is enabled regardless of whether Mach3 is doing anything or not.  Mach3 can command KFLOP to move an axis somewhere.  But whether it does this or not will not result in drift.

Drift occurs simply when the Drives are enabled but the KFLOP Axes are not enabled.

Here is your drift scenario:

#1 EStop Bit active - your C Program loop Disables the Drives and Disables the KFLOP Axes

#2 EStop Bit deactiveated - your C Program Enables the Drives only - causing drift

What might work is to move the code that enables the drives before the loop to execute one time only whenever the Init Program is executed.  In this case:

#1 EStop Bit active - your C Program loop Disables the Drives and Disables the KFLOP Axes

#2 EStop Bit deactiveated - nothing really happens (except Mach3 is notified)

#3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and Drives

HTH

Regards

TK

On 3/2/2017 8:37 PM, harnett harnett@... [DynoMotion] wrote:

 

Guess I didn't explain well.   Mach3 doesn't do anything to the kflop i/o that I've programed.   Kflop is in full control of all i/o.    I am controlling all i/o via the c program.    The question really is about what happens  between kflop and mach3 via the driver.

The goal is that I must keep bits 152 to 156 set anytime I'm in an estop condition or Mach3 is not control the position of the axis

"When I go to estop"  When I push my hardwired estop button power is removed from the drives and kflop input bit 143 is made active.    In my c program this disables all axis and sets bits 152 to 156.    This is all fine and works well and with bits 152 to 156 set no creep from the drives since the outputs are hardwired to the drive disable inputs.

"When I come out of estop" When I pull out my estop button power is turned on to the drives and kflop input bit 143 is made inactive.   

This is where I need advice.    The only i/o bit I have mapped between kflop and mach3 is the Estop bit.   It looks like mach3 reruns the c program when the estop bit is made inactive.    With my c program this renables the axis but mach3 isn't controlling the drives until I click the "software reset button" in Mach3.    So between pulling the estop button out and clicking the "software reset button" I get axis creep.

I don't want to clear bits 152 to 156 I'm not in estop confition AND until Mach3 is controlling the axis.   How can I do this.    With my c program it would be as simple as something like this if I knew a bit to look at.   Maybe you have a better idea.

// if ESTOP or Mach3 is not in control present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143

        #define Mach3InControl_BIT  ???

        if  (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

I see that Mach3 has enable 1 to 6 outputs.    Can't find any documentation that says what the do in Mach3.  am I over thinking this.  Can I just map those Mach3 enables bits to bits 152 to 156 in kflop.    If I knew how that react maybe is really is that simple and I don't need the c program to do it.

On 3/2/2017 10:37 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Regarding Drift:

I'm not sure exactly what you mean by "When I go to estop" and "when I come out of estop".

Actually Mach3 doesn't ever "control the drives".  It only sets/clears enable outputs and runs your init program.

You didn't tell us how you have Mach3 configured.  I'm guessing you have the Mach3 ports&pins Enable bits configured configured to also control your Amp enable bits (152 - 156)?  I think that may be the problem.  Mach3 intentionally sets the enable outputs one by one with delays (to supposedly avoid a current surge) and then does the Reset.  So in the mean time the drives may drift.  it would probably be better to set Mach3 to dummy bits and let KFLOP and your init program be in full control of the enables.

HTH

Regards

TK

On 3/2/2017 5:39 PM, harnett harnett@... [DynoMotion] wrote:

 

Ok here is the info I was able to gather  Kflop 4.33 Build 18:05:42 Dec 1 2015,    Mach 3 Version R3.043.066

I've attached the log file but all I saw was "Dynomotion Status: Comm Error"   which is what was shown at the bottom status bar of Mach3.   Kflop/ Kanalog have a dedicated power supply.    I'll have to investigate further on the reboot issue and get back to you.

The firmware message I get is "DPS_KMotion Date Stamp Doesn't Match Kmotion Firmware"  I'll get a screen shot the next time this happens.   These two issue happen infrequently.    The firmware issue has happened maybe 6 times and the Comm Error message only once.    I'll try to gather more info if you don't have any ideas at this time.


On another more straight forward issue.   I am controlling my drives with an analog signal.   As we've talked about before when kflop is not controlling the drive the voltage may not be exactly zero and I see some small movement in the drive.   I am working around this by using a disable input on the drive attached to output on kflop.    I've tied this output to the axis enable in my c program so that if the axis is disabled I turn on the output and disable the drive electrically.   This works fine in kmotion and keeps the drive from creeping.   I trigger this when I go to estop.   Problem is when I'm in Mach3.   When I go to estop all is well and works fine.    But when I come out of estop I have a issue.    When I electrically disengage the estop I think mach3 runs the c program.  Which re enables the drive but Mach3 doesn't start controlling the drive until I press the reset buttion in the Mach3 software.   So between those two steps the drive creeps.      I can see on the Mach3 software that it is monitoring the estop bit and the frame of the reset button changes color when I disengage the estop.     How can I keep my drives disabled until Mach3 is in control.    If there was a bit to look at I could just do an or condition with the estop bit.   Both would have to be ready before the drive was enabled.    Any thoughts on how I can do this.   Maybe you see another way to do my c program that will be better.    


I attached my c program file but here is the relative code to axis enabling at the end.



    EnableAxis(0);   
    EnableAxis(1);
    EnableAxis(2);
    EnableAxis(3);
    EnableAxis(4);


    DefineCoordSystem(0,2,3,-1);


    for (;;)  //loop forever
    {
        WaitNextTimeSlice();

        // if ESTOP present disable any enabled Axis and set disable bit??
         #define ESTOP_BIT 143
        if  (!(ReadBit(ESTOP_BIT)))
         {       
            if (ch0->Enable)            // axis still enabled?  - Disable it
                    DisableAxis(0); 
                    SetBit(152);
            if (ch1->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(1);       
                    SetBit(153);
            if (ch2->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(2);
                    SetBit(154);

            if (ch3->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(3);
                    SetBit(155);

            if (ch4->Enable)               // axis still enabled?  - Disable it
                    DisableAxis(4);
                    SetBit(156);

         }

        // if Axis enabled , clear disabled bit
        if (ch0->Enable)
            ClearBit(152);
       
        if (ch1->Enable)
            ClearBit(153);   

        if (ch2->Enable)
            ClearBit(154);
                   
        if (ch3->Enable)
            ClearBit(155);
           
        if (ch4->Enable)
            ClearBit(156);

                                   
    }


return 0;

}

On 2/27/2017 2:55 PM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Hi Barry,

Sorry to hear that.

You are correct about the Firmware Version being checked whenever you run the Initialization C Program.  It is checked whenever any C Program is executed.  And the Firmware Version should never change on its own.  More likely it is somehow being miss read.  That's why I asked you to report the Time Stamps in the error messages in my last email.

It sounds like you are confusing the Firmware with something else.  KMotion doesn't check or report if the Firmware is already up to date.  Exactly what message to you receive?  Maybe you are referring to the Windows Driver?

How are you supplying +5V to KFLOP+Kanalog?

You might want to determine if KFLOP is resetting/rebooting which would cause a communication error.  Or if only a communication error has occurred.  One trick I sometimes do is to manually turn off one of KFLOP's LEDs.  Then if the LED turns back on I know KFLOP re-booted.

Please specify the versions of KMotion and Mach3 (please don't say the latest as that can be somewhat vague).

Regards

TK

On 2/27/2017 6:02 AM, harnett@... [DynoMotion] wrote:

 

Tom,

Still having this issue.   There is not a lot of history on the machine in that it is a new retrofit with DMM drives, Kflop and Mach3.    Very little run time.   Maybe 50 hours total.   It may run fine for hours then I'll get this Firmware error message.   Yesterday I booted everything up.  Maybe up about 30 min.  Was jogging around getting ready for a run and got the Firmware error.   Rebooted and started running a job.  After around three hours of running I got an error message in Mach3 that said "Communication Error with Dynomotion"     First time I've seen this.    My C program only contains the initialization routine for the axis.     Is it possible that something about the usb communication between the PC and Kflop could cause these type of errors.   The pc is windows XP, Kflop is the latest firmware.  Mach3 is the latest version.   PC is not going to sleep.   

If I understand you, when mach3 starts and the c-program initialization routine is run the firmware version in kflop is checked and compared to the c-program.    all is well there.    My gcode is created in Vectrics.   My firmware error has always happened after mach3 is up a running, axes have been moved around and all is well initially.     A few times it occurred in the middle of executing  a gcode program and as I mention while I was jogging the axes around but the initial firmware check passed when mach3 was started.   The firmware has never been changed.   I did try to update it but kmotion says the latest firmware is already install so firmware is not the issue.   It feels like I'm losing communication periodically but I'm not sure why.

On 2017-03-03 13:31, harnett harnett@... [DynoMotion] wrote:
> I'll try moving the code thanks. It really doesn't need to be in the
> loop anyway. I can see that BUT if Mach3 is not running the first
> part of Init.c until I press reset then it really should work the way
> it is to right.
>
> "What might work is to move the code that enables the drives before
> the loop to execute one time only whenever the Init Program is
> executed. "
>
> EnableAxis(0);
> EnableAxis(1);
> EnableAxis(2);
> EnableAxis(3);
> EnableAxis(4); Is part of my Init.c code so the EnableAxis(x)
> statements shouldn't run until init.c is run. So as it currently
> is. Estop active, C Program loop Disables the Drives and Disables the
> KFLOP Axes
>
> The if statement in my loop watches for all the axis to be enabled but
> it doesn't enable them. I see what you are saying, it would work at
> the end of init.c to but it looks like Mach3 is running init.c when
> the estop bit is deactivated because the drives are being enabled
> before I push reset in software or my current c program would keep the
> axis and drives disabled.
>
> Am I missing something big on the init.c file. I sent you the
> entire file but what I thought was happening was the first part with
> the axis setups , then the Enableaxis statements then the
> DefineCoordsystem statement ran once and the my loop ran forever
> watching the estop.
>
> So if that's true the EnableAxis shouldn't run until the first part of
> init.c is rerun.
>
> Would I be better off to link Mach3 enable 1-5 to the kflop bits
> 152-156 I can't really find any information that tells me exactly
> how Mach3 uses those outputs but maybe that's what the are for. I'd
> really rather keep it in kflop though.
>
> I just need some robust code that keeps the bits link to the axis
> enable at all times then all would be well. Again, I'll test what
> you suggested tomorrow but I don't really understand why the current
> code doesn't work, though I fully see your suggestion as better code.
> No reason to continually test for enable when the only why they
> should get reenalbed is when the first part of init.c is run.
>
> On 3/3/2017 2:43 PM, Tom Kerekes tk@... [DynoMotion] wrote:
>
>> Hi Barry,
>>
>> Ok I think I get it.
>>
>> On a minor note, I repeat, Mach3 never really "controls the
>> position of the axis" in a manner regarding drift. KFLOP always
>> controls the position of the axis to avoid drift while an axis is
>> enabled regardless of whether Mach3 is doing anything or not. Mach3
>> can command KFLOP to move an axis somewhere. But whether it does
>> this or not will not result in drift.
>>
>> Drift occurs simply when the Drives are enabled but the KFLOP Axes
>> are not enabled.
>>
>> Here is your drift scenario:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - your C Program Enables the Drives only -
>> causing drift
>>
>> What might work is to move the code that enables the drives before
>> the loop to execute one time only whenever the Init Program is
>> executed. In this case:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - nothing really happens (except Mach3 is
>> notified)
>>
>> #3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and
>> Drives
>>
>> HTH
>>
>> Regards
>>
>> TK
>>
>> On 3/2/2017 8:37 PM, harnett harnett@... [DynoMotion]
>> wrote:
>>
>> Guess I didn't explain well. Mach3 doesn't do anything to the
>> kflop i/o that I've programed. Kflop is in full control of all
>> i/o. I am controlling all i/o via the c program. The question
>> really is about what happens between kflop and mach3 via the
>> driver.
>>
>> The goal is that I must keep bits 152 to 156 set anytime I'm in an
>> estop condition or Mach3 is not control the position of the axis
>>
>> "When I go to estop" When I push my hardwired estop button power is
>> removed from the drives and kflop input bit 143 is made active.
>> In my c program this disables all axis and sets bits 152 to 156.
>> This is all fine and works well and with bits 152 to 156 set no
>> creep from the drives since the outputs are hardwired to the drive
>> disable inputs.
>>
>> "When I come out of estop" When I pull out my estop button power is
>> turned on to the drives and kflop input bit 143 is made inactive.
>>
>>
>> This is where I need advice. The only i/o bit I have mapped
>> between kflop and mach3 is the Estop bit. It looks like mach3
>> reruns the c program when the estop bit is made inactive. With my
>> c program this renables the axis but mach3 isn't controlling the
>> drives until I click the "software reset button" in Mach3. So
>> between pulling the estop button out and clicking the "software
>> reset button" I get axis creep.
>>
>> I don't want to clear bits 152 to 156 I'm not in estop confition AND
>> until Mach3 is controlling the axis. How can I do this. With my
>> c program it would be as simple as something like this if I knew a
>> bit to look at. Maybe you have a better idea.
>>
>> // if ESTOP or Mach3 is not in control present disable any enabled
>> Axis and set disable bit??
>> #define ESTOP_BIT 143
>>
>> #define Mach3InControl_BIT ???
>>
>> if (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
>> {
>> if (ch0->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(0);
>> SetBit(152);
>> if (ch1->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(1);
>> SetBit(153);
>> if (ch2->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(2);
>> SetBit(154);
>>
>> if (ch3->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(3);
>> SetBit(155);
>>
>> if (ch4->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(4);
>> SetBit(156);
>>
>> I see that Mach3 has enable 1 to 6 outputs. Can't find any
>> documentation that says what the do in Mach3. am I over thinking
>> this. Can I just map those Mach3 enables bits to bits 152 to 156 in
>> kflop. If I knew how that react maybe is really is that simple
>> and I don't need the c program to do it.
>>

OK,

I'll gather more info.   Just to be clear.   This only happens in Mach3.   In Kmotion when I enable and disable the axis manually everything works fine.  No drift at all.   This is where I tested my code and thought all was well.

>>

>> #1 EStop Bit active - your C Program loop Disables the

>> Disables the KFLOP Axes
>>

>> #2 EStop Bit deactivated - nothing really happens (except

>> notified)
>>

>> #3 User Pushes "RESET" in Mach3 - Init.c runs enabling the

>> Drives
>>

 

Hi Barry,

You are absolutely correct. My mistake. It didn't sink in that the
Drive Enables will only happen if the Axes are somehow enabled.

So now it doesn't make sense. I can't see any way the drives could ever
be enabled without the KFLOP Axes also enabled.

Before you make any functional changes let's please analyze exactly what
is going on.

Please add a printf statement to the beginning of the the Init C Program
so we can see on the Console whenever it is called.

Then do your scenario:

#1 Activate EStop

#2 Deactivate EStop

Is the system drifting? If so which axes? Check if the Amps are
enabled by observing the Digital IO Screen. Check if the KFLOP Axes are
enabled by observing the Axis Screen. Check if there was a new Printout
on the Console Screen.

Regards
TK

On 2017-03-03 13:31, harnett harnett@... [DynoMotion] wrote:
> I'll try moving the code thanks. It really doesn't need to be in the
> loop anyway. I can see that BUT if Mach3 is not running the first
> part of Init.c until I press reset then it really should work the way
> it is to right.
>
> "What might work is to move the code that enables the drives before
> the loop to execute one time only whenever the Init Program is
> executed. "
>
> EnableAxis(0);
> EnableAxis(1);
> EnableAxis(2);
> EnableAxis(3);
> EnableAxis(4); Is part of my Init.c code so the EnableAxis(x)
> statements shouldn't run until init.c is run. So as it currently
> is. Estop active, C Program loop Disables the Drives and Disables the
> KFLOP Axes
>
> The if statement in my loop watches for all the axis to be enabled but
> it doesn't enable them. I see what you are saying, it would work at
> the end of init.c to but it looks like Mach3 is running init.c when
> the estop bit is deactivated because the drives are being enabled
> before I push reset in software or my current c program would keep the
> axis and drives disabled.
>
> Am I missing something big on the init.c file. I sent you the
> entire file but what I thought was happening was the first part with
> the axis setups , then the Enableaxis statements then the
> DefineCoordsystem statement ran once and the my loop ran forever
> watching the estop.
>
> So if that's true the EnableAxis shouldn't run until the first part of
> init.c is rerun.
>
> Would I be better off to link Mach3 enable 1-5 to the kflop bits
> 152-156 I can't really find any information that tells me exactly
> how Mach3 uses those outputs but maybe that's what the are for. I'd
> really rather keep it in kflop though.
>
> I just need some robust code that keeps the bits link to the axis
> enable at all times then all would be well. Again, I'll test what
> you suggested tomorrow but I don't really understand why the current
> code doesn't work, though I fully see your suggestion as better code.
> No reason to continually test for enable when the only why they
> should get reenalbed is when the first part of init.c is run.
>
> On 3/3/2017 2:43 PM, Tom Kerekes tk@... [DynoMotion] wrote:
>
>> Hi Barry,
>>
>> Ok I think I get it.
>>
>> On a minor note, I repeat, Mach3 never really "controls the
>> position of the axis" in a manner regarding drift. KFLOP always
>> controls the position of the axis to avoid drift while an axis is
>> enabled regardless of whether Mach3 is doing anything or not. Mach3
>> can command KFLOP to move an axis somewhere. But whether it does
>> this or not will not result in drift.
>>
>> Drift occurs simply when the Drives are enabled but the KFLOP Axes
>> are not enabled.
>>
>> Here is your drift scenario:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - your C Program Enables the Drives only -
>> causing drift
>>
>> What might work is to move the code that enables the drives before
>> the loop to execute one time only whenever the Init Program is
>> executed. In this case:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - nothing really happens (except Mach3 is
>> notified)
>>
>> #3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and
>> Drives
>>
>> HTH
>>
>> Regards
>>
>> TK
>>
>> On 3/2/2017 8:37 PM, harnett harnett@... [DynoMotion]
>> wrote:
>>
>> Guess I didn't explain well. Mach3 doesn't do anything to the
>> kflop i/o that I've programed. Kflop is in full control of all
>> i/o. I am controlling all i/o via the c program. The question
>> really is about what happens between kflop and mach3 via the
>> driver.
>>
>> The goal is that I must keep bits 152 to 156 set anytime I'm in an
>> estop condition or Mach3 is not control the position of the axis
>>
>> "When I go to estop" When I push my hardwired estop button power is
>> removed from the drives and kflop input bit 143 is made active.
>> In my c program this disables all axis and sets bits 152 to 156.
>> This is all fine and works well and with bits 152 to 156 set no
>> creep from the drives since the outputs are hardwired to the drive
>> disable inputs.
>>
>> "When I come out of estop" When I pull out my estop button power is
>> turned on to the drives and kflop input bit 143 is made inactive.
>>
>>
>> This is where I need advice. The only i/o bit I have mapped
>> between kflop and mach3 is the Estop bit. It looks like mach3
>> reruns the c program when the estop bit is made inactive. With my
>> c program this renables the axis but mach3 isn't controlling the
>> drives until I click the "software reset button" in Mach3. So
>> between pulling the estop button out and clicking the "software
>> reset button" I get axis creep.
>>
>> I don't want to clear bits 152 to 156 I'm not in estop confition AND
>> until Mach3 is controlling the axis. How can I do this. With my
>> c program it would be as simple as something like this if I knew a
>> bit to look at. Maybe you have a better idea.
>>
>> // if ESTOP or Mach3 is not in control present disable any enabled
>> Axis and set disable bit??
>> #define ESTOP_BIT 143
>>
>> #define Mach3InControl_BIT ???
>>
>> if (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
>> {
>> if (ch0->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(0);
>> SetBit(152);
>> if (ch1->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(1);
>> SetBit(153);
>> if (ch2->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(2);
>> SetBit(154);
>>
>> if (ch3->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(3);
>> SetBit(155);
>>
>> if (ch4->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(4);
>> SetBit(156);
>>
>> I see that Mach3 has enable 1 to 6 outputs. Can't find any
>> documentation that says what the do in Mach3. am I over thinking
>> this. Can I just map those Mach3 enables bits to bits 152 to 156 in
>> kflop. If I knew how that react maybe is really is that simple
>> and I don't need the c program to do it.
>>

Tom,

Turns out it wasn't in the software but the way I was supplying power.   The kflop FETs were not seeing proper voltage.    The software was working properly.     Your suggestions really helped me find it.  Thanks.

// z axis selector
         #define ZaxisSelectorSwitch_BIT 143
        if  (!(ReadBit(ZaxisSelectorSwitch_BIT)))

                    // Use z axis #1 for z axis

                    printf("Z Axis #1 selected!\n");  // send message to console

                    DefineCoordSystem(0,2,3,-1);

        Else

                    // Use z axis #2 for z axis

                    printf("Z Axis #1 selected!\n");  // send message to console                  

                    DefineCoordSystem(0,2,4,-1);

 

OK,

I'll gather more info.�� Just to be clear.�� This only happens in Mach3.�� In Kmotion when I enable and disable the axis manually everything works fine.� No drift at all.�� This is where I tested my code and thought all was well.

>>
In Mach3
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
No Drift at all on any axis

>> #2 EStop Bit deactivated - nothing really happens (except Mach3 is
>> notified)
>>
This is when axis drift.�� All axis do it to some degree

>> #3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and
>> Drives
>>
All axis stop and no drift.��� Machine runs gcode and cuts fine.


I think you are saying to have Mach3 and Kmotion running at the same time to monitor the axis enable/disable to see what's happening.�� I appears to me that when the Estop bit is deactivated that the axis are being re-enabled.� That's why I'm getting drift.�� Will that printf statement write to the logfile?��
Looking at the ccode examples I think this is the right syntax.

printf("Init Program Executed!\n");� // send message to console

I'll see what I can come up with for more data.

On 3/3/2017 5:03 PM, tk@... [DynoMotion] wrote:

�

Hi Barry,

You are absolutely correct. My mistake. It didn't sink in that the
Drive Enables will only happen if the Axes are somehow enabled.

So now it doesn't make sense. I can't see any way the drives could ever
be enabled without the KFLOP Axes also enabled.

Before you make any functional changes let's please analyze exactly what
is going on.

Please add a printf statement to the beginning of the the Init C Program
so we can see on the Console whenever it is called.

Then do your scenario:

#1 Activate EStop

#2 Deactivate EStop

Is the system drifting? If so which axes? Check if the Amps are
enabled by observing the Digital IO Screen. Check if the KFLOP Axes are
enabled by observing the Axis Screen. Check if there was a new Printout
on the Console Screen.

Regards
TK

On 2017-03-03 13:31, harnett harnett@... [DynoMotion] wrote:
> I'll try moving the code thanks. It really doesn't need to be in the
> loop anyway. I can see that BUT if Mach3 is not running the first
> part of Init.c until I press reset then it really should work the way
> it is to right.
>
> "What might work is to move the code that enables the drives before
> the loop to execute one time only whenever the Init Program is
> executed. "
>
> EnableAxis(0);
> EnableAxis(1);
> EnableAxis(2);
> EnableAxis(3);
> EnableAxis(4); Is part of my Init.c code so the EnableAxis(x)
> statements shouldn't run until init.c is run. So as it currently
> is. Estop active, C Program loop Disables the Drives and Disables the
> KFLOP Axes
>
> The if statement in my loop watches for all the axis to be enabled but
> it doesn't enable them. I see what you are saying, it would work at
> the end of init.c to but it looks like Mach3 is running init.c when
> the estop bit is deactivated because the drives are being enabled
> before I push reset in software or my current c program would keep the
> axis and drives disabled.
>
> Am I missing something big on the init.c file. I sent you the
> entire file but what I thought was happening was the first part with
> the axis setups , then the Enableaxis statements then the
> DefineCoordsystem statement ran once and the my loop ran forever
> watching the estop.
>
> So if that's true the EnableAxis shouldn't run until the first part of
> init.c is rerun.
>
> Would I be better off to link Mach3 enable 1-5 to the kflop bits
> 152-156 I can't really find any information that tells me exactly
> how Mach3 uses those outputs but maybe that's what the are for. I'd
> really rather keep it in kflop though.
>
> I just need some robust code that keeps the bits link to the axis
> enable at all times then all would be well. Again, I'll test what
> you suggested tomorrow but I don't really understand why the current
> code doesn't work, though I fully see your suggestion as better code.
> No reason to continually test for enable when the only why they
> should get reenalbed is when the first part of init.c is run.
>
> On 3/3/2017 2:43 PM, Tom Kerekes tk@... [DynoMotion] wrote:
>
>> Hi Barry,
>>
>> Ok I think I get it.
>>
>> On a minor note, I repeat, Mach3 never really "controls the
>> position of the axis" in a manner regarding drift. KFLOP always
>> controls the position of the axis to avoid drift while an axis is
>> enabled regardless of whether Mach3 is doing anything or not. Mach3
>> can command KFLOP to move an axis somewhere. But whether it does
>> this or not will not result in drift.
>>
>> Drift occurs simply when the Drives are enabled but the KFLOP Axes
>> are not enabled.
>>
>> Here is your drift scenario:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - your C Program Enables the Drives only -
>> causing drift
>>
>> What might work is to move the code that enables the drives before
>> the loop to execute one time only whenever the Init Program is
>> executed. In this case:
>>
>> #1 EStop Bit active - your C Program loop Disables the Drives and
>> Disables the KFLOP Axes
>>
>> #2 EStop Bit deactiveated - nothing really happens (except Mach3 is
>> notified)
>>
>> #3 User Pushes "RESET" in Mach3 - Init.c runs enabling the Axes and
>> Drives
>>
>> HTH
>>
>> Regards
>>
>> TK
>>
>> On 3/2/2017 8:37 PM, harnett harnett@... [DynoMotion]
>> wrote:
>>
>> Guess I didn't explain well. Mach3 doesn't do anything to the
>> kflop i/o that I've programed. Kflop is in full control of all
>> i/o. I am controlling all i/o via the c program. The question
>> really is about what happens between kflop and mach3 via the
>> driver.
>>
>> The goal is that I must keep bits 152 to 156 set anytime I'm in an
>> estop condition or Mach3 is not control the position of the axis
>>
>> "When I go to estop" When I push my hardwired estop button power is
>> removed from the drives and kflop input bit 143 is made active.
>> In my c program this disables all axis and sets bits 152 to 156.
>> This is all fine and works well and with bits 152 to 156 set no
>> creep from the drives since the outputs are hardwired to the drive
>> disable inputs.
>>
>> "When I come out of estop" When I pull out my estop button power is
>> turned on to the drives and kflop input bit 143 is made inactive.
>>
>>
>> This is where I need advice. The only i/o bit I have mapped
>> between kflop and mach3 is the Estop bit. It looks like mach3
>> reruns the c program when the estop bit is made inactive. With my
>> c program this renables the axis but mach3 isn't controlling the
>> drives until I click the "software reset button" in Mach3. So
>> between pulling the estop button out and clicking the "software
>> reset button" I get axis creep.
>>
>> I don't want to clear bits 152 to 156 I'm not in estop confition AND
>> until Mach3 is controlling the axis. How can I do this. With my
>> c program it would be as simple as something like this if I knew a
>> bit to look at. Maybe you have a better idea.
>>
>> // if ESTOP or Mach3 is not in control present disable any enabled
>> Axis and set disable bit??
>> #define ESTOP_BIT 143
>>
>> #define Mach3InControl_BIT ???
>>
>> if (!(ReadBit(ESTOP_BIT)or !(ReadBit(Mach3InControl_BIT))
>> {
>> if (ch0->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(0);
>> SetBit(152);
>> if (ch1->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(1);
>> SetBit(153);
>> if (ch2->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(2);
>> SetBit(154);
>>
>> if (ch3->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(3);
>> SetBit(155);
>>
>> if (ch4->Enable) // axis still enabled? -
>> Disable it
>> DisableAxis(4);
>> SetBit(156);
>>
>> I see that Mach3 has enable 1 to 6 outputs. Can't find any
>> documentation that says what the do in Mach3. am I over thinking
>> this. Can I just map those Mach3 enables bits to bits 152 to 156 in
>> kflop. If I knew how that react maybe is really is that simple
>> and I don't need the c program to do it.
>>

Hi Barry,

Something like that could work. 

But you might also switch with a C Program triggered by an M6 Tool Change.  Based on the "Slot" number being 1 or 2 the C Program can Define the Coordinate System appropriately.  It can also save the "Slot" in a global persist variable so other Spindle programs like those for M3, M4, M5, S can decide which Spindle they should control.  This provides the advantages of:

#1 programmatically switch spindles like an automatic tool changer without the need for the operator to toggle a switch.

#2 The Tool table xy offsets (and lengths) can be used to automatically compensate between the locations of the two spindle axes.

HTH

Regards

TK

 

Tom,

Turns out it wasn't in the software but the way I was supplying power.   The kflop FETs were not seeing proper voltage.    The software was working properly.     Your suggestions really helped me find it.  Thanks.

If I haven't used up my question quota I'd like advice on something else.    My machine is a retrofitted thermwood cnc router with 2   z axis.     I don't need to use them both at the same time but would like to be able to use both at different times.   Sort of like a  two tool, tool changer.     I have both wired and working to Kflop.   One on channel 3 and one on channel 4.    I was thinking a selector switch to an input on kflop and something in init.c like this.   Would this work or do you have a better idea of a way to do this.

// z axis selector
         #define ZaxisSelectorSwitch_BIT 143
        if  (!(ReadBit(ZaxisSelectorSwitch_BIT)))

                    // Use z axis #1 for z axis

                    printf("Z Axis #1 selected!\n");  // send message to console

                    DefineCoordSystem(0,2,3,-1);

        Else

                    // Use z axis #2 for z axis

                    printf("Z Axis #1 selected!\n");  // send message to console                  

                    DefineCoordSystem(0,2,4,-1);

Any thoughts would be appreciated

Thanks,

Barry